Design Round 7 · Deliverable 3 · Collaboration through the server · renders canon 2026-07-11 · July 11, 2026

Collaboration — through the server, inside grants

Two trusted members in one Project: Elias and Moe in the Lightbrush integration. Presence and handoffs (3a), files, sync, and working on each other's machines — all mediated by the server, everything traced (3b) — the trust boundary rendered honestly as the four-quadrant matrix (3c), and one moment of the Sentinel's effect (3d).

Presence is position; a handoff is a said thing

In the Field, a collaborator's presence is where they are and what they're near — never a green dot with a timer. A handoff is spoken, carried by the server, and lands as an ACTION at the other end.

Kiduna Studio · Elias's view project · Lightbrush integration Field · both · Chat

Elias · at the adapter Records

Moe · at RenderDeck · working on his machine

test render · sent by Moe · arriving

The Ceremony Machine · Lightbrush integration

Moe sent you a test render through the server — it lands when you take it, not before.

chat · Elias's ally, for Elias

action · file from Moe

dolly-test-render.mp4 · 240 MB · held on the server under this Project's grants. Taking it syncs it to your machine and records the transfer.

take itleave it on the server

Moe's note came with it: "Dolly's output with the new adapter — watch the last ten seconds." The handoff is recorded either way.

nothing moves member-to-member directly — the server mediates, the grant scopes, the record traces

desktop 1440 (shown scaled) · presence is position, not status · "working on his machine" is stated where Moe stands, because his machine is a place work happens, not a mystery

The server is the trusted middle: files, sync, and presence all pass through it, so every exchange is scoped by grants and leaves a Record — and neither member ever reaches into the other's space uninvited.

No presence meters: no "active 2h", no typing indicators across members. You see where someone is and what they said. Their ally answers "is Moe around?" honestly, in a sentence, within what Moe shares.

Working on each other's machines — a grant, said out loud

What a trusted relationship unlocks: Elias can run the adapter's builds on Moe's render machine — because Moe granted exactly that, the server carries every command, and both sides watch the same trace. Untrusted relationships cannot do this at all; there is no "request access" flow to escalate one — trust is established between people, in conversation, then stated to allies.

grant · within the Elias ⇄ Moe relationship · trusted

in effect

Elias may run builds on Moe's render machine

Scope — the Lightbrush integration Project only · the adapter workspace only · build and test commands only

Path — every command travels Studio → server → Moe's machine and returns the same way; nothing runs that the server didn't carry

Trace — both members see the same log, as sentences; Moe's copy shows every command verbatim

Ends — when the Project closes, or when either says so — "revoke Elias's build access" is a complete revocation

running now · told as it happens

14:02 · build adapter-dolly @ moe-render-01 · started by Elias
14:04 · tests 41/41 passed · output held on the server
14:04 · Moe's ally told Moe, in his register: "Elias built on your machine; all green."

the grant card — front is the consequence; the trace is a shared fact, not a surveillance feed

What trusted unlocks (and untrusted doesn't): sending files that sync · state that syncs both ways · running granted commands on each other's machines · allies speaking to each other with standing context. Untrusted relationships still converse and still exchange — but nothing lands on a machine, nothing syncs, and every artifact stays server-held at arm's length.

The member's machine stays theirs: the ally coordinates, it doesn't colonize (Integrations §1). The grant names commands, not disk access; there is no remote desktop, no file browser into someone's life.

The four quadrants — without fear language

Relationships are trusted or untrusted; resources are registered or unregistered. Four combinations, all legal, all workable — the matrix describes standing, never safety. Inside the shared Project, each quadrant is one sentence about what the thing can do.

trusted relationship · registered resource

Digital Dolly, brought by Moe

Full standing: it acts inside the Project's grants, its work Records cite it by name, its outputs sync to trusted members' machines, and its usage flows through the duna's recorded configuration.

trusted relationship · unregistered resource

RenderDeck, before Moe registers it

Works here, known here: it acts inside this Project only, its Records say "via RenderDeck (unregistered)," and nothing it makes travels beyond the Project until it's registered. Dashed border, plain words.

untrusted relationship · registered resource

A registry tool from another ecosystem

Known everywhere, close to no one: the registry vouches for what it is; the untrusted relationship means exchanges stay server-held — you can use its outputs, cite them, pay for them; nothing syncs, nothing runs on a member's machine.

untrusted relationship · unregistered resource

A one-off script from a stranger's server

A visitor at the counter: it can hand things over and take things offered publicly. Its artifacts arrive marked with exactly that provenance, and members decide, case by case, whether any of it enters the record.

No quadrant is "dangerous." Each is a stated distance — and distance is rendered as geometry and line quality, never as warning color.

The two axes never blur (law): trusted/untrusted belongs to relationships between parties; registered/unregistered belongs to resources. A registered resource is never called "trusted," and registration alone never earns closeness.

Movement between quadrants is conversational: "register RenderDeck" is a command with a receipt; trusting a relationship is the two people saying so, each to their own ally.

The Sentinel's effect — a pacing nudge, no meters, ever

Hour five of a hot working session: Elias and Moe have been trading builds fast, and the last three exchanges got shorter and sharper. The Sentinel acts through the allies — pacing, not correction. Nothing renders as an instrument; each member hears one plain sentence, from their own ally, in their own register.

Elias's chat · his ally

Send it back to him again — the color's still wrong and I said where.

I'll send it. The render takes about twenty minutes either way — this might be a good stretch to step out of the room; I'll bring you back the moment it lands.

the nudge is the pause the work already contained, surfaced — never "you two seem tense"

what Elias sees — one sentence with an honest reason; declining costs nothing and is never mentioned again

what happened underneath · never rendered to members

The Sentinel read the exchange rhythm in its ambient band and acted agent-side only: adjust_pacing on both allies — Elias's ally folds the natural pause into its next answer; Moe's ally, twenty minutes later, opens with the render result instead of the backlog. Both acts are logged, inspectable in the Vigil on demand. No number, no reading, no acronym ever reaches a member.

the annotation is for this canvas only — Studio itself never shows this panel

The design rule: the Sentinel is visible only as effects and plain sentences. In Studio that means pacing lives inside the ally's ordinary helpfulness — a well-timed suggestion with a true reason — and is indistinguishable from good manners, because that's what it is.